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-Abstract- 

A key challenge when statically typing so-called dynamic languages is the ubiquity of value-based 
overloading, where a given function can dynamically reflect upon and behave according to the 
types of its arguments. Thus, to establish basic types, the analysis must reason precisely about 
values, but in the presence of higher-order functions and polymorphism, this reasoning itself can 
require basic types. In this paper we address this chicken-and-egg problem by introducing the 
framework of two-phased typing. The hrst “trust” phase performs classical, i.e. flow-, path- and 
value-insensitive type checking to assign basic types to various program expressions. When the 
check inevitably runs into “errors” due to value-insensitivity, it wraps problematic expressions 
with DEAD-casts, which explicate the trust obligations that must be discharged by the second phase. 
The second phase uses rehnement typing, a flow- and path-sensitive analysis, that decorates the 
hrst phase’s types with logical predicates to track value relationships and thereby verify the casts 
and establish other correctness properties for dynamically typed languages. 
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[T] Introduction 

Higher-order constructs are increasingly adopted in dynamic scripting languages, as they 
facilitate the production of clean, correct and maintainable code. Consider, for example, the 
following (hrst-order) JavaScript function 

function minIndexFO (a) { 
if (a.length < 0) 
return -1; 
var min = 0; 

for (var i = 0; i < a.length; i++) { 
if (a[i] < a[min]) 
min = i ; 

} 

return min ; 

} 
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function $reduce(a, f, x) { 
van res = x, i = 0; 
for (i = 0; i < a.length; i++) 
res = f(res , a[i] , i+ + ); 
return res; 

} 

function reduce(a, f, x) { 
if (arguments.length === 3) 
return $reduce(a, f, x); 
return $reduce(a, f, a[0]); 

} 


function minlndex(a) { 
if (a.length < 0) 
return -1; 

function step(min, cur, i) { 
return cur < a[min] ? i:min; 

} 

return reduce(a, step, 0); 


M Figure 1 Computing the minimum-valued index with Higher-Order Functions 


which computes the index of the minimum value in the array a by looping over the array, 
updating the min value with each index i whose value a[i] is smaller than the “current” 
a[min]. Modern dynamic languages let programmers factor the looping pattern into a 
higher-order $reduce function (Figure 1), which frees them from manipulating indices and 
thereby prevents the attendant “off-by-one” mistakes. Instead, the programmer can compute 
the minimum index by supplying an appropriate f to reduce as in minindex shown at the 
right of Figure 1. 

This trend towards abstraction and reuse poses a challenge to static program analyses: 
how to precisely trace value relationships across higher-order functions and containers? A 
variety of dataflow- or abstract interpretation- based analyses could be used to verify the 
safety of array accesses in minIndexFO by inferring the loop invariant that i and min are 
between 0 and a. length. Alas, these analyses would fail on minindex. The usual methods 
of procedure summarization apply to first-order functions, and it is not clear how to extend 
higher-order analyses like CFA to track the relationships between the values and closures 
that flow to $reduce. 

An Approach: Refinement Types. Refinement types [31] hold the promise of a precise 
and compositional analysis for higher-order functions. Here, basic types are decorated with 
refinement predicates that constrain the values inhabiting the type. For example, we can 
define 

type idx<x> = {vrnumber | 0 < v && v < len(x) } 

to denote the set of valid indices for an array x and can be used to type $reduce as 

$reduce :: <A,B>(a: A[], f: (B,A,idx<a>)=>B, x: B)=>B 

The above type is a precise relational summary of the behavior of $reduce: the higher-order 
f is only invoked with valid indices for a. Consequently, step is only called with valid indices 
for a, which ensures array safety. 

Problem: Value-based Overloading. A main attraction of dynamic languages is value- 
based overloading, where syntactic entities {e.g. variables) may be bound to multiple types 
at run-time, and furthermore, computations may be customized to particular types, by 
reflecting on the values bound to variables. For example, it is common to simplify APIs 
by overloading the reduce function to make the initial value x optional; when omitted, the 
first array element a[0] is used instead. Here, reduce really has two different function types: 
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one with 3 parameters and another one with 2. Furthermore, reduce reflects on the size of 
arguments to select the behavior appropriate to the calling context. 

Value-based overloading conflicts with a crucial prerequisite for refinements, namely that 
the language possesses an unrefined static type system that provides basic invariants about 
values which can then be refined using logical predicates. Unfortunately, as shown by reduce, 
to soundly establish basic typing we must reason about the logical relationships between 
values, which, ironically, is exactly the problem we wished to solve via refinement typing. In 
other words, value-based overloading creates a chicken-and-egg problem: refinements require 
us to first establish basic typing, but the latter itself requires reasoning about values (and 
hence, refinements!). 

Solution: Trust but Verify. We introduce two-phased typing, a new strategy for statically 
analyzing dynamic languages. The key insight is that we can completely decouple reasoning 
about basic types and refinements into distinct phases by converting “type errors” from the 
first phase into “assertion failures” for the second. Two-phase typing starts with a source 
language where value-based overloading is specified using intersections and (untagged) unions 
of the different possible (run-time) types. 

The first phase performs classical, i.e. flow-, path- and value-insensitive type checking 
to assign basic types to various program expressions. When the check inevitably runs into 
“errors” due to value-insensitivity, it wraps problematic expressions with DEAD-casts which 
allow the first phase to proceed, trusting that the expressions have the casted types. In other 
words, the first phase elaborates [10] the source language with intersection and (untagged) 
union types, into a target ML-like language with classical products, (tagged) sums and 
DEAD-casts, which explicate the trust obligations that must be discharged by the second phase. 
The second phase carries out refinement, i.e. flow- and path-sensitive inference, to decorate 
the basic types (from the first phase) with predicates that precisely track relationships about 
values, and uses the refinements to verify the casts and other properties, discharging the 
assumptions of the first phase. 

For example, reduce is described as the intersection of two contexts, i.e. function types 
which take two and three parameters respectively. The trust-phase checks the body under 
both contexts (separately). In each context, one of the calls to $reduce is “ill-typed”. In 
the context where the function takes two inputs, the call using x is undefined; when the 
function takes three inputs, there is a mismatch in the types of f and a[0]. Consequently, 
each ill-typed expression is wrapped with a cast which obliges the verify phase to prove that 
the call is dead code in that context, thereby verifying overloading in a cooperative manner. 

Benefits. While it is possible to account for value-based overloading in a single phase, the 
currently known methods that do so are limited to the extremes of types and program logics. 
At one end, systems like Typed Racket [28] and Flow Typing [16] extend classical type 
systems to account for a fixed set of typeof-style tests, but cannot reason about general 
value tests {e.g. the size of arguments) that often appear in idiomatic code. At the other end, 
systems like System D [7] embed the typing relation in an expressive program logic, allowing 
general value tests, but give up on basic type structure, thereby sacrificing inference, causing 
a significant annotation overhead. In contrast, our approach separates the concerns of basic 
typing and reasoning about values, thereby yielding several concrete benefits by modularizing 
specification, verification and soundness. 

H Specification: Instead of a fixed set of type-tests, two-phase typing handles complex 

value relationships which can be captured inside refinements in an expressive logic. 
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neg :: (number, number) =J> number 

var 

a = neg (1 , 1 ) ; 

// 

OK 

A (number , boolean) => boolean 

var 

b = neg (0, true); 

// 

OK 

function neg(flag, x) { 

var 

c = neg (0,1) ; 

// 

ERR 

if (flag) return 0-x; 

var 

d = neg (1 , true) ; 

// 

ERR 


return !x; 

} 


M Figure 2 An example program with value-based overloading 


Furthermore, the expressiveness of the basic type system and logics can be extended 
independently, e.g. to account for polymorphism, classes or new logical theories, directly 
yielding a more expressive specification mechanism. 

H Verification: Two-phase typing enables the straightforward composition of simple type 
checkers (uncomplicated by reasoning about values) with program logics (relying upon 
the basic invariants provided by typing - e.g. the parametric polymorphism needed to 
verify minindex). Furthermore, two-phase typing allows us to compose basic typing with 
abstract interpretation [23], which drastically lowers the annotation burden for using 
refinement types. 

H Soundness: Finally, our elaboration-based approach makes it straightforward to establish 
soundness for two-phased typing. The first phase ignores values and refinements, so we 
can use classical methods to prove the elaborated target is “equivalent to” the source. The 
second phase uses standard refinement typing techniques on the well-typed elaborated 
target, and hence lets us directly reuse the soundness theorems for such systems [18] to 
obtain end-to-end soundness for two-phased typing. 


Contributions. Concretely, in this paper we make the following contributions. First, we 
informally illustrate (§ 2) how two-phase typing lets us statically analyze dynamic, value- 
based overloading patterns drawn from real-world code, where, we empirically demonstrate, 
value-based overloading is ubiquitous. Second, we formalize two-phase typing using a core 
calculus, Rsc, whose syntax and semantics are detailed in § 3. Third, we formalize the first 
phase (§ 4), which elaborates [10] a source language with value-based overloading into a 
target language with DEAD-casts in lieu of overloading. We prove that the elaborated target 
preserves the semantics of the source, i.e. the DEAD-casts fail iff the source would hit a type 
error at run time. Finally, we demonstrate how standard refinement typing machinery can be 
applied to the elaborated well-typed target (§ 5) to statically verify the DEAD-casts, yielding 
end-to-end soundness for our system. 

2 I Overview 

We begin with an overview illustrating how we soundly verify value-based overloading using 
our novel two-phased approach. 

2.1 Value-based Overloading 

Consider the code in Figure 2. The function neg behaves as follows. When a number is passed 
as input, indicated by passing in a non-zero, i.e. “truthy” flag, the function flips its sign by 
subtracting the input from 0. Instead, when a boolean is passed in, indicated by a zero, i.e. 
“falsy” flag, the function returns the boolean negation. Hence, the calls made to assign a 
and b are legitimate and should be statically accepted. However, the calls made to assign c 
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and d lead to run-time errors (assuming we eschew implicit coercions), and hence, should be 
rejected. 

The function neg distils value-based overloading to its essence: a run-time test on one 
parameter’s value is used to determine the type of, and hence the operation to be applied to, 
another value. Of course in JavaScript, one could use a single parameter and the typeof 
operator for this particular simple case, and design analyses targeted towards a fixed set of 
type tests, e.g. using variants of the typeof operator [28, 16]. However, arbitrary value tests 
- such as tests of the size of arguments shown in reduce in Figure 1 - can be and are used in 
practice. Thus, we illustrate the generality of the problem and our solution without using 
the typeof operator (which is a special case of our solution). 


Prevalence of Value-based Overloading. The code from Figure 1 is not a pathological 
toy example. It is adapted from the widely used D3 visualization library. The advent 
of TypeScript makes it possible to establish the prevalence of value-based overloading in 
real-world libraries, as it allows developers to specify overloaded signatures for functions. 
(Even though TypeScript does not verify those signatures, it uses them as trusted interfaces 
for external JavaScript libraries and code completion.) The Definitely Typed repository ^ 
contains TypeScript interfaces for a large number of popular JavaScript libraries. We analyzed 
the TypeScript interfaces to determine the prevalence of value-based overloading. Intuitively, 
every function or method with multiple (overloaded) signatures or optional arguments has 
an implementation that uses value-based overloading. 

Figure 3 summarizes the results of our study. On the left, we show the fraction of 
overloaded functions in the 10 benchmarks analyzed by Feldthaus et al. [12]. The data shows 
that over 25% of the functions in 4 of 10 libraries use value-based overloading, and an even 
larger fraction is overloaded in libraries like jquery and d3. On the right we summarize 
the occurrence of overloading across all the libraries in Definitely Typed. The data shows, 
for example, that in more than 25% of the libraries, more than 25% of the functions are 
overloaded with multiple types. The figure jumps to nearly 55% of functions if we also 
include optional arguments. 

The signatures in Definitely Typed have not been soundly checked against^ their imple¬ 
mentations. Hence, it is possible that they mischaracterize the semantics of the actual code, 
but modulo this caveat, we believe the study demonstrates that value-based overloading is 
ubiquitous, and so to soundly and statically analyze dynamic languages, it is crucial that we 
develop techniques that can precisely and flexibly account for it. 


2.2 Refinement Types 

Types and Refinements. A basic refinement type T is a basic type, e.g. number, refined 
with a logical formula from an SMT decidable logic - for the purposes of this paper, the 
quantifier-free logic of uninterpreted functions and linear integer arithmetic (QF_UFLIA [25]). 
For example, {v: number | v != 0} describes the subset of numbers that are non-zero. We 
write A to abbreviate the trivially refined type {;/:A | true}, e.g. number is an abbreviation 
for number | true}. 


^ http://definitelytyped.org 

^ Feldthaus et al. [12] describe an effective but unsound inconsistency detector. 
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File 
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3 
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M Figure 3 The prevalence of value-based overloading. (L) Libraries from [12]: ^^^Funs is the 
number of functions in the signature, %Ovl is %-functions with multiple signatures, %Opt is 
%-functions with optional arguments, and %Any is %-functions with either of these features. (R) 
Overloading across all files in DefinitelyTyped. A point {x,y) means y% of files have more than 
x% overloaded functions. 


Summaries: Function Types. We can specify the behavior of functions with refined function 
types, of the form 

{xi :Ti,...,Xn-Tn)^T 

where arguments are named Xi and have types Ti and the output is a T. In essence, the 
input types specify the function’s preconditions, and the output type T describes the 
postcondition. Furthermore, each input type and the output type can refer to the arguments 
Xi which yields precise function contracts. For example, 

(a::0 < x) number | x < 

is a function type that describes functions that require a non-negative input, and ensure that 
the output is greater than the input. 

Example. Returning to neg in Figure 2, we can define two refinements of number: 

type tt = {vinumber | v != 0} // "truthy" numbers 

type ff = {v: number | v = 0} // "falsy" numbers 

which are used to specify a refined type for neg shown on the left in Figure 4. 


Problem: A Circular Dependency. While it is easy enough to specify a type signature, it is 
another matter to verify it, and yet another matter to ensure soundness. The challenge is that 
value-based overloading introduces a circular dependency between types and refinements. The 
soundness of basic types requires (i.e. is established by) the refinements, while the refinements 
themselves require {i.e. are attached to) basic types. In classical refinement systems like 
DML [31], basic types are established without requiring refinements. A classical refinement 
system is thus a conservative extension of the corresponding non-refined language, i.e. 
removing the refinements from a DML program, yields valid, well-typed ML. Unfortunately, 
value-based overloading removes this crucial property, posing a circular dependency between 
types and refinements. 
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neg :: (tt, number) =J> number 


neg#1 :: (tt, number) =J> number 


A (ff, boolean) => boolean 


function neg#1(flag, x) { 
if (flag) return 0-x; 
return !DEAD(x) ; 


function neg(flag, x) { 
if (flag) return 0-x; 
return !x; 


} 


} 


neg#2 :: (ff, boolean) boolean 


function neg#2(flag, x) { 
if (flag) return O-DEAD(x); 
return !x; 


} 

var neg = (neg#1, neg#2) ; 


var a = neg (1,1); //OK 

var b = neg(0,true); //OK 

var c = neg(0,l); //ERR 

var d = neg(1,true); //ERR 


var a = fst (neg) (1 , 1) ; //OK 
var b = snd( neg) (0, true ); //OK 
var c = fst( neg) (0,1); //ERR 
var d = snd (neg) (1 , true) ; //ERR 


M Figure 4 Source program (1) and target (r) resulting from first phase elaboration. 

Solution: Two-Phase Checking. We break the cycle by typing programs in two phases. 
In the first, we trust the basic types are correct and use them (ignoring the refinements) to 
elaborate source programs into a target overloading-free language. Inevitably, value-based 
overloading leads to “errors” when typing certain sub-expressions in the wrong context, e.g. 
subtracting a boolean-valued x from 0. Instead of rejecting the program, the elaboration 
wraps ill-typed expressions with DEAD-casts, which are assertions stating the program is 
well-typed assuming those expressions are dead code. In the second phase we reuse classical 
refinement typing techniques to verify that the DEAD-casts are indeed unreachable, thereby 
discharging the assumptions made in the first phase. 


2.3 Phase 1: Trust 


The first phase elaborates the source program into an equivalent typed target language 
with two key properties: First, the target program is simply typed - i.e. has no union 
or intersection types, but just classical ML-style sums and products. Second, source-level 
type errors are elaborated to target-level DEAD-casts. The right side of Figure 4 shows the 
elaboration of the source from the left side. While we formalize the elaboration declaratively 
using a single judgment form (§ 4), it comprises two different steps. Critically, each step, 
and hence the entire first phase, is independent of the refinements - they are simply carried 
along unchanged. 

A. Clone. In the first step, we create separate clones of each overloaded function, where 
each clone is assigned a single conjunct of the original overloaded type. For example, we 
create two clones neg#1 and neg#2 respectively typed using the two conjuncts of the original 
neg. The binder neg is replaced with a tuple of its clones. Finally, each use of neg extracts 
the appropriate element from the tuple before issuing the call. 

Since the trust phase must be independent of refinements, the overload resolution in this 
step uses only the basic types at the call-site to determine which of the two clones to invoke. 
For example, in the assignment to a, the source call neg(1 ,1 ) - which passes in two number 
values, and hence, matches the first overload (conjunct) - is elaborated to the target call 
fst(neg)(1 ,1). In the assignment to d, the source call neg(1 ,true) - which passes in a 
number and a boolean, and hence matches the second overload - is elaborated to the target 
call snd(neg)(1 ,true), even though 1 does not have the refined type ff. 
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B: Cast. In the second step we check - using classical, unrefined type checking - that each 
clone adheres to its specified type. Unlike under usual intersection typing [22, 10], in our 
context these checks almost surely “fail”. For example, neg#1 does not type-check as the 
parameter x has type number and so we cannot compute !x. Similarly, neg#2 fails because x 
has type boolean and so 0-x is erroneous. Rather than reject the program, we wrap such 
failures with DEAD-casts. For example, the above occurrences of x elaborate to DEAD(x) on 
the right in Figure 4. 

Intuitively, the value relationships established at the call-sites and guards ensure that 
the failures will not happen at run-time. However, recall that the first phase’s goal is to 
decouple reasoning about types from reasoning about values. Hence, we just trust all the 
types but use DEAD-casts to explieate the value-relationship obligations that are needed to 
establish typing: namely that the DEAD-casts are indeed dead code. 

2.4 Phase 2: Verify 

The second phase takes as input the elaborated program emitted by the first phase, which 
is essentially a classical well-typed ML program with assertions and without any value¬ 
overloading. Hence, the second phase can use any existing program logic [14, 4], refinement 
typing [31, 18, 23, 2], or contracts & abstract interpretation [20] to check that the target’s 
assertions never fail, which, we prove, ensures that the source is type-safe. 

To analyze programs with closures, collections and polymorphism, {e.g. minindex from 
Figure 1) we perform the second phase using the refinement types that are carried over 
unchanged by the elaboration process of the first phase. Intuitively, refinement typing can 
be viewed as a generalization of classical program logics where assertions are generalized to 
type bindings, and the rule of consequence is generalized as subtyping. While refinement 
typing is a previously known technique, to make the paper self-contained, we illustrate how 
the second phase verifies the DEAD-casts in Figure 4. 

Refinement Type Checking. A refinement type checker works by building up an environ¬ 
ment of type bindings that describe the machine state at each program point, and by checking 
that at each call-site, the actual argument’s type is a refined subtype of the expected type 
for the callee, under the context described by the environment at that site. The sub typing 
relation for basic types is converted to a logical verification condition whose validity is checked 
by an SMT solver. The subtyping relation for compound types {e.g. functions, collections) 
is decomposed, via co- and contra-variant subtyping rules, into subtyping constraints over 
basic types, which can be discharged as above. 

Typing DEAD-Casts. To use a standard refinement type checker for the second phase of 
verification, we only need to treat DEAD as a primitive operation with the refined type: 

DEAD :: VA, : A \ false}) B 

That is, we assign DEAD the precondition false which states there are no valid inputs for it, 
i.e. that it should never be called (akin to assert(false) in other settings). 

Environments. To verify DEAD-casts, the refinement type checker builds up an environment 
of type binders describing variables and branch conditions that are in scope at each program 
point. For example, the DEAD call in neg#1, has the environment: 


Fi =flag:tt, x:number, gj^ boolean j flag = 0} 


(1) 
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where the first two bindings are the function parameters, whose types are the input types. 
The third binding is from the “else” branch of the flag test, asserting the branch condition 
flag is “falsy” i.e. equals 0. At the DEAD call in neg#2 the environment is: 


r 2 =flag:ff, x:boolean, gj^ boolean | flag 0} (2) 

At the assignments to a, b and c the environments are respectively: 

Ta = neg:rneg (3) 

Tb = Tq, a: number (4) 

Tc = Tft, b:boolean (5) 

where Tneg abbreviates the product type of the (elaborated) tuple neg. 

Tneg = ((tt, number) => number) x ((ff, boolean) => boolean) (6) 


Subtyping. At each function call-site, the refinement type system checks that the actual 
argument is indeed a subtype of the expected one. For example, the DEAD calls inside neg#1 
and neg#2 yield the respective subtyping obligation: 

Fi h {;/: number I z/= x} C {z/: number | /alse} (7) 

F 2 F {z/: boolean I 1 /= x} C {z/: boolean |/oZse} (8) 

The obligation states that the type of the argument x should be a subtype of the input 
type of DEAD. Similarly, at the assignments to a, b and c the first arguments generate the 
respective subtyping obligations: 


FaF 

{zy: number 

zy=l} 

C 

{zy: number | 

z/^0} 

(9) 

FfcF 

{zy: number 

zy = 0} 

c 

{zy: number | 

zy = 0} 

(10) 

FcF 

{zy: number 

zy = 0} 

c 

{zy: number | 

zy^O} 

(11) 


Verification Conditions. To verify subtyping obligations, we convert them into logical 
verification conditions (VCs), whose validity determines whether the subtyping holds. A 
subtyping obligation T h { 1 /:b \ p} ^ {v:b \ q} translates to the VC [F] ^ (p g) where 
|r] is the conjunction of the refinements of the binders in F. For example, the subtyping 
obligations (7) and (8) yield the respective VCs: 

(flag ^ 0 A frwe A flag = 0) zy = x => false (12) 

(flag = 0 A frwe A flag 0) zy = x => false (13) 

Here, the conjunct true arises from the trivial refinements e.g. the binding for x. The above 
VCs are deemed valid by an SMT solver as the hypotheses are inconsistent, which proves the 
call is indeed dead code. Similarly, (9), (10) respectively yield VCs: 

true zy=l => zy^^O 

true zy = 0 zy = 0 

which are deemed valid by SMT, verifying the assignments to a, b. However, by (11): 

true zy = 0 => zy^^O (16) 

which is invalid, ensuring that we reject the call that assigns to c. 


(14) 

(15) 
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2.5 Two-Phase Inference 

Our two-phased approach readily lends itself to abstract interpretation based refinement 
inference which can drastically lower the programmer annotations required to verify various 
safety properties, e.g. reducing the annotations needed to verify array bounds safety in ML 
programs from 31% of code size to under 1% [23]. Here we illustrate how inference works 
in the presence of value-based overloading. Suppose we are not given the refinements for 
the signature of neg but only the unrefined signature (either given to us explicitly as in 
TypeScript, or inferred via dataflow analysis [16, 11]). As inference is difficult with incorrect 
code, we omit the erroneous statements that assign to c and d. 

Refinement inference proceeds in three steps. First, we create templates which are the 
basic types decorated with refinement variables k in place of the unknown refinements. 
Second, we perform the trust phase to elaborate the source program into a well-typed target 
free of overloading. Remember that this phase uses only the basic types and is oblivious 
to the (in this case unknown) refinements. Third, we perform the verify phase which now 
generates VCs over the refinement variables k. These VCs - logical implications between the 
refinements and k variables - correspond to so-called Horn constraints over the k variables, 
and can be solved via abstract interpretation [13, 23]. 

0. Templates: Let us revisit the program from Figure 2, with the goal of inferring the 
refinements. Recall that the (unrefined) type of neg is: 

neg :: (number, number) =:> number 
A (number,boolean) boolean 

We create a template by refining each base type with a (distinct) refinement variable: 

neg :: ({i^:number j ki}, {j/: number j K 2 ]) => {;z:number j K 3 } 

A ({j^:number j K 4 }, boolean j K 5 }) => {i^iboolean j kq} 

1. Trust: The trust phase proceeds as before, propagating the refinements to the signatures 
of the elaborated target, yielding the code on the right in Figure 4 except that neg#1 and 
neg#2 have the respective templates: 

neg #1 :: ({^: number j ki}, number j K 2 }) ^ number j Ata} 

neg #2 :: ({j/:number j K 4 }, boolean j K 5 }) => {A/:boolean j kq] 

2. Verify: The verify phase proceeds as before, but using templates instead of the types. 
Hence, at the DEAD-cast in neg#1 and neg#2, and the calls to neg that assign to a and b, 
instead of the VCs (12), (13), (14) and (15), we get the respective Horn constraints: 


(ki [flag/j/] A frwe A flag = 0) => v = v. ^ false (17) 

(k4 [flag/j/] A frwe A flag ^ 0) => v = x => false (18) 

true => A/ = 1 => Ki (19) 

true => V = 0 => AC4 (20) 


These constraints are identical to the corresponding VCs except that k variables appear 
in place of the unknown refinements for the corresponding binders. We can solve these 
constraints using fixpoint computations over a variety of abstract domains such as monomial 
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predicate abstraction [13, 23] over a set of ground predicates which are arithmetic (in)equalities 
between program variables and constants, to obtain a solution mapping each k to a concrete 
refinement: 


Ki = ly = 0 = V 0 K 2 , K3, K5, Ke = true 

which, when plugged back into the templates, allow us to infer types for neg. 

Higher-Order Verification. Our two-phased approach generalizes directly to offer precise 
analysis for polymorphic, higher-order functions. Returning to the code in Figure 1, our 
two-phased inference algorithm infers the refinement types: 

$reduce :: MA, B.{a\A[\,f\{B,A,iAx{a)) B,x:B) B 
reduce :: \/A.{a:A[]'^,f: {A, A, idx(a)) ^ 

A yA,B.{a:A[],f:{B,A,idx{a)) => B,x:B) B 

where idx(a) describes valid indices for array a, and A[]+ describes non-empty arrays: 

idx(a) = {;/: number | 0 < < len(a)} 

= {'^•^[] I 0 < len(i^)} 

The above type is a precise summary for the higher-order behavior of $reduce: it describes 
the relationship between the input array a, the step (“callback”) function /, and the initial 
value of the accumulator, and stipulates that the output satisfies the same properties B as 
the input x. Furthermore, it captures the fact that the callback / is only invoked on inputs 
that are valid indices for the array a that is being reduced. Consequently, Liquid Types [23], 
for example, would automatically infer: 

step :: VA.(idx(a), A, idx(a)) idx(a) 
minindex :: VA.(A[]) number 

thereby verifying the safety of array accesses in the presence of higher order functions, 
collections, and value-based overloading. 

[~y] Syntax and Operational Semantics of Rsc 

Next, we formalize two-phase typing via a core calculus Rsc comprising a source language 
AO with overloading via union and intersection types, and a simply typed target language 
without overloading, where the assumptions for safe overloading are explicated via DEAD-casts. 
In § 4, we describe the first phase that elaborates source programs into target programs, 
and finally, in § 5 we describe how the second phase verifies the DEAD-casts on the target to 
establish the safety of the source. Our elaboration follows the overall compilation strategy 
of Dunfield [10] except that we have value-based overloading instead of an explicit “merge” 
operator [22], and consequently, our elaboration and proofs must account for source level 
“errors” via DEAD-casts. 

3.1 Source Language (AO) 

Terms. We define a source language AO, with syntax shown in Figure 5. Expressions include 
variables, functions, applications, let-bindings, a ternary conditional construct, and primitive 
constants c which include numbers 0,1,..., operators -E, —,..., etc. 
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Source Language: Syntax 

Values V 

Expressions e ::= 


c 

V 


X I Xx.e 
let a; = ei in ea 


e ? ei : 62 | ei 62 


Primitive Types B 
Types A, B 


Num I Bool 

B I B I AaB I AV B 


Source Language: Operational Semantics 



E-ECtx 



E[e] E[e'] 


E-Cond-True 
true ? Cl : 62 —^ ei 


E-App-1 
cv —^ |c](r) 

E-Cond-Ealse 
false ? ei ; 62 —62 


E-App-2 

(Xx.e) V —> [v/x] e 
E-Let 

let a; = R in e — [v/x] 


e 


H Figure 5 Syntax and Operational Semantics of AO 


Operational Semantics. In figure 5 we also define a standard small-step operational se¬ 
mantics for \y with a left-to-right order of evaluation, based on evaluation contexts 

E ::= {) I let x = E in e \ E 1 ei : €2 \ E e \ v E 

Types. Figure 5 shows the types A in the source language. These include primitive types 
B, arrow types A ^ B and, most notably, intersections A A B and (untagged) unions AV B 
(hence the name AO). Note that the source level types are not refined, as crucially, the first 
phase ignores the refinements when carrying out the elaboration. 

Tags. As is common in dynamically typed languages, runtime values are associated with 
type tags, which can be inspected with a type test (cf. JavaScript’s typeof operator). We 
model this notion to our static types, by associating each type with a set of possible tags. 
The multiplicity arises from unions. The meta-function TAG(A), defined in Figure 6, returns 
the possible tags that values of type A may have at runtime. 

Well-Formedness. In order to resolve overloads statically, we apply certain restrictions on 
the form of union and intersection types, shown by the judgment h A formalized in Figure 6. 
For convenience of exposition, the parts of an untagged union need to have distinct runtime 
tags, and intersection types require all conjuncts to have the same tag. 

3.2 Target Language (A+) 

The target language eliminates (value-based) overloading and thereby provides a basic, 
well-typed skeleton that can be further refined with logical predicates. Towards this end, 
unions and intersections are replaced with classical tagged unions, products and DEAD-casts, 
that encode the requirements for basic typing. 

Terms. Figure 7 shows the terms M of A(^, which extend the source language with the 
introduction of pairs, projections, injections, a case-splitting construct and a special constant 
term DEADalb(M) which denotes an erroneous computation. Intuitively, a DEAD aw {^) is 
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Well-Formed Types 


h A 


hB 


h A h B 

A h B TAG(T) = TAG(B) 

h AAB 


h A h B 
TAG(yl) n TAG(B) = 0 
' h AVB 


TAG(Num) = {"number"} 
TAG(Bool) = {"boolean"} 
TAG(A^A') = {"function"} 


TAG(A a A’) = TAG(A) 

TAG(A V A') = TAG(A) U TAG(A') 


M Figure 6 Basic Type Well-Formedness 


Target Language: 

Expressions M, N 


Values W 


Syntax 

::= c I X I Xx.M \ M ? Mi : Ma | Mi Ma 
I {Ml,M2) I projfeAf I inji M | inja M 
I case M of inji xi =:► Mi | inj2 X2 Ma | DEADaiiB(M) 

::= c I X I Xx.M \ inji W | inja W | (M, M) | DEADaiis(lT) 


Ref. Types T, S 


{u-.M I p} I x:T^ S I T+S \ T X S 


Target Language: Operational Semantics 



TE-ECtx 
M —> M' 

£[M] —>£[^] 


TE-App-1 

DEADaib{W') 

ciM^[cl(W) 


TE-App-2 

{Xx.M) W —^ [W/x] M 


TE-Cond-True 

true ? Ml : M2 —S> Mi 


TE-Cond-False TE-Let 

false 1 Ml : M2 —> M2 let x = IT in M —^ [W/x] M 


TE-Proj 

projfc(Mi,M2) —^ Mk 


TE-Case 

case injj, W of inji xi ^ Mi | inja xa ^ M2 —)■ [W/xk] Mk 


M Figure 7 Syntax and Operational Semantics of 


produced in the elaboration phase whenever the actual type A for a term M is incompatible 
with an expected type B. 

Operational Semantics. As in the source language we define evaluation contexts 

£ ::= ( ) I let x = £ in M | £ 1 Mi : M 2 | £ M | u £ | inj^. £ 

I projj.£ I DEADyiiB(£) | case £ of inji xi ^ Mi I inJa xa ^ Ma 

and use them to define a small-step operational semantics for the target in Figure 7. Note 
how evaluation is allowed in DEAD-casts and DEAD,4 ib(1T) is a value. 

Types. The target language is checked against a refinement type checker. Thus, we modify 
the type language to account for the new language terms and refinements. Basic Refinement 
Types are of the form {:/:B | p}, consisting of the same basic types B as source types, and a 
logical predicate p (over some decidable logic), which describes the properties that values 
of the type must satisfy. Here, is a special value variable that describes the inhabitants 
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of the type, that does not appear in the program, but can appear inside the refinement p. 
Function types are of the form a;: T —> S', to express the fact that the refinement predicate of 
the return type S may refer to the value of the argument x. Sum and product types have 
the usual structure found in ML-like languages. 

Phase 1: Trust 

Terms of Ay are elaborated to terms of by a judgment: The:: M. This is read: 

under the typing assumptions in T, term e of the source language is assigned a type A and 
elaborates to a term M of the target language. This judgment follows closely Dunfield’s 
elaboration judgment [10], but with crucial differences that arise due to dynamic, value-based 
overloading, which we outline below. 

Elaboration Ignores Refinements. A key aspect of the first phase is that elaboration is 
based solely on the basic types, i.e. does not take type refinements into account. Hence, the 
types assigned to source terms are transparent with respect to refinements; or more precisely, 
they work just as placeholders for refinements that can be provided as user specifications. 
These specifications are propagated as is during the first phase along with the respective 
basic types they are attached to. Due to this transparency of refinements we have decided to 
omit them entirely from our description of the elaboration phase. 

4.1 Source Language Type-checking and Elaboration 

Figure 8 shows the rules that formalize the elaboration process. At a high-level, following 
Dunfield [10], unions and intersections are translated to simpler typing constructs like sums 
and products (and the attendant injections, pattern-matches, and projections). Unlike the 
above work, which focuses on the classical intersection setting where overloading is explicit 
via a “merge” construct [22], we are concerned with the dynamic setting where overloading 
is value-based, leading to conventional type “errors”. 

Elaboration Modes: Strict and Flexible. Thus, one of the distinguishing features of our 
type system is its ability to not fail in cases where conventional static type system would 
raise type incompatibility errors, but instead elaborate the offending terms to the special 
error form DEAD^ 4 ^b(M). However, these error forms do not appear indiscriminately, but 
under certain conditions, specified by two elaboration modes: (1) a flexible judgment (fy.) 
for rules that may yield DEAD, 4 ^b(M) terms, and (2) a strict judgment (f^ ) for those that 
don’t. Most elaboration rules come in both flavors, depending on the surrounding rules in a 
typing derivation. We write a to parameterize over the two modes. 

Intuitively, we use flexible mode when checking calls to non-overloaded functions (with 
a single conjunct) and strict mode when checking calls to overloaded ones. In the former 
case, a type incompatibility truly signals a (potential) run-time error, but in the latter case, 
incompatibility may indicate the wrong choice of overload. Consequently, the elaboration 
judgment also states whether the intersection rule has been used, or not, by annotating the 
hook-arrow with the label y or n, respectively. As with strictness, we parametrize over n 
and y with the variable 9, and use * to denote that the outcome is not important. 

Top-level Elaboration. Our top-level judgment is agnostic of either of the aforementioned 
modes. Elaborating programs in an empty context (h) is essentially elaborating in the flexible 
sense and assumes we are not in the context of intersection elimination (T-TopLevel). 
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Elaboration Typing 


• e :: M 

T-TopLevel ----. 

•he:: M 


The:: M 


Ths e:: M 

T-Weaken - - -g- 

r e :: ^4 M 


T-Cst 

r c :: ty_c^ c 


T-Let 


r ei :: Ai^ Mi T,x:Ai 1^ 62 :: ^ 2 ^ M 2 

Q 

r let X = ei in 62 :: ^2^ let x = Mi in M2 


T-Var 


x:A&T 
0 

r h X :: A^ X 


T-If 


r fi;, e :: Bool-^ M Vi G { 1 , 2 } . T Ci :: A^ M, 

0 

r e ? ei : 62 :: A^ M ? Mi : M2 


T-AI 


V/c G { 1 , 2 } . r X :: Mj, h Ti A AI2 

r Ai A ^24 (Mi, M 2 ) 


T-AE 


r e :: Ali A hl2^ M 
r 1^ e :: ^^4 projj,AV 


T-Lam 


\-A ^ B r,x: A e :: M 

r h Ax.e :: A — > i?4 Xx.M 


T-T 


r fi:, e :: A-a M TAG(A) n TAG(S) = 
r fi:. e :: b 4 DEADAiB(M) 


T-App 


vln 

r ei :: A ^ b4 Mi 
r Ig/F 62 :: A^ AI2 


T-VI 


r hi ei 62 :: B^ Mi M2 

r e :: Af h V A2 

r e :: Ai V A2^ inj^, M 


T-VE 


r, xi: Ai hi £'[xi] :: B^ Mi 

r hi Co ■ ■ ^1 V A2‘— >■ Mg r, X2 : A2 hi £'[2^2] :: B’-^ M2 

0 

r £’[eo] :: B^ case Mg of inji xi Mi | inj2 X2 M2 


Figure 8 Elaboration Typing rules 


Furthermore, an elaboration that succeeds in strict mode also succeeds in flexible mode 
(T-Weaken), so all strict rules can be used as flexible ones. 

Standard Rules. Rules T-Cst, T-Var are standard and preserve the structure of the 
source program. Rule T-If expects the condition e of a conditional expression e ? ei : 62 to 
be of boolean type, and assigns the same type A to each branch of the conditional. Rule 
T-Let checks expressions of the form let x = ei in 62. It assigns a type Ai to expression ei 
and checks 62 in an environment extended with the binding of Ai for x. 

Intersections. In rule T-AI the choice of the type we assign to a value v causes different 
elaborated terms Wk, as different typing requirements cause the addition of DEAD-casts at 
different places. This rule is intended to be used primarily for abstractions, so it’s limited 
to accept values as input. Rule T-AE for eliminating intersections replaces a term e that 
is originally typed as an intersection with a projection of that part of the pair that has a 
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matching type. By T-AI values typed at an intersection get a pair form. 

Unions. Rule T-VI for union introduction is standard. The union elimination rule, taken 
from Dunfield’s elaboration scheme [10], states that an expression eg can be assigned a union 
type Ai V A 2 when placed at the “hole” of an evaluation context E, so long as the evaluation 
context can be typed with the same type B, when the hole is replaced with a variable typed 
as Ai on the one hand and as A 2 on the other. While the rule is inherently non-deterministic, 
it suffices for a declarative description of the elaboration process; see Dunfield’s subsequent 
work on untangling type-checking of intersections and unions [9] for an algorithmic variant 
via a let-normal conversion. 

Abstraction and Application. Rule T-Lam assumes the arrow type A ^ B is given as 
annotation and is required to conform to the well-formedness constraints. At the crux of our 
type system is the rule T-APP. Expression ei can be typed in flexible mode. Depending 
on whether intersection elimination was used for ei we toggle on the mode of checking 
62 . To only allow sensible derivations, we disallow the use of the DEAD-cast insertion when 
choosing among the cases of an intersection type. Below, we justify this choice using an 
example. If on the other hand, the type for ei is assigned without choosing among the parts 
of an intersection, then expression 62 can be typed in flexible mode, potentially producing 
DEAD-casts. 

Trusting via DEAD-Casts. The cornerstone of the “trust” phase lies in the presence of the 
T-T rule. As we mentioned earlier, this rule can only be used in flexible mode. The main 
idea here is to allow cases that are obviously wrong, as far as the simple first phase type 
system is concerned; but, at the same time, include a DEAD-cast annotation and defer sound 
type-checking for the second phase. The premises of this rule specify that a DEAD-cast 
annotation will only be used if the inferred and the expected type have different tags. One of 
the consequences of this decision is that it does not allow DEAD-casts induced by a mismatch 
between higher-order types, as the tags for both types would be the same (most likely 
"function"). Thus, such mismatches are ill-typed and rejected in the first phase. This 
limitation is due to the limited information that can be encoded using the tag mechanism. A 
more expressive tag mechanism could eliminate this restriction but we omit this for simplicity 
of exposition. 

Semantics of DEAD-Casts. To prove that elaboration preserves source level behaviors, our 
design of DEAD-casts preserves the property that the target gets stuck iff the source gets 
stuck. That is, source level type “errors” do not lead to early failures {e.g. at function 
call boundaries). Instead, DEAD-casts correspond to markers for all source terms that can 
potentially cause execution to get stuck. Hence, the target execution itself gets stuck at the 
same places as the source - i.e. when applying to a non-function, branching on a non-boolean 
or primitive application over the wrong base value, except that in the target, the stuckness 
can only occur when the value in question carries a DEAD marker. Consider the source program 
(Ax.a; 1) 0 which gets stuck after the top-level application, when applying 1 to 0. It could be 
elaborated to (Ax.x 1) DEADai£( 0) (where A and B are respectively Num and Num —> Num) 
which also has a top-level application and gets stuck at the second, inner application. 

Necessity of elaboration modes. If we allowed the argument of an overloaded call-site to 
be checked in flexible context, then for the application / x, where / has been assigned the 
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type / :!— >IAB— 7 >B and x : B, the following derivation would be possible: 


T-AE 


... [y, f proji/ 


T-_L 


10 

.. . fy, X :: B^ X 

TAG(B) n TAG(I) = 0 

... [y, X :: DEADBii(a;) 


T-App — 

/:I^IAB->B,a;:Bly, / a;::lA (proji/) (DEADbie (x)) 
But, clearly, the intended derivation here is: 


T-AE 


T-App 


. .. hp f proj2/ 


... X :: B^ X 


/:!—>IAB—>'B,a:::B[y, f x :: B^ (proj 2 /) x 


Subtyping. This formulation has been kept simple with respect to subtyping. The only 
notion of subtyping appears in the T-VI rule, where a type Ai is widened to Ai V A 2 . We 
could have employed a more elaborate notion of subtyping, by introducing a subtyping 
relation (<) and a subsumption rule for our typing elaboration. The rules for this sub typing 
relation would include, among others, function subtyping: 

A) ^ Ai A 2 ^ A 2 

Ai —)■ A2 ^ Ai —^ A2 

However, supporting subtyping in higher-order constructs would only be possible with the 
introduction of wrappers around functions to accommodate checks on the arguments and 
results of functions. So, assuming that a cast c represents a dynamic check the above rule 
would correspond to a cast producing relation ([>): 


Ai D> Ai ■ > Cl A2 A2 


C2 


Ai —>■ A2 A) —>■ A2 Xf .Xx.{c2 (/ (ci a;))) 

This formulation would just complicate the translation without giving any more insight in 
the main idea of our technique, and hence we forgo it. 

4.2 Source and Target Language Consistency 

In this section, we present the theorems that precisely connect the semantics of source 
programs with their elaborated targets. The main challenges towards establishing those are 
that: (1) the source and target do not proceed in lock-step, a single step of the one may 
be matched by several steps of the other (for example evaluating a projection in the target 
language does not correspond to any step in the source language), and (2) we must design 
the semantics of the DEAD-casts in the target to ensure that DEAD-casts cause evaluation to 
get stuck iff some primitive operation in the source gets stuck. We address these, next, with 
a number of lemmas and state our assumptions. 

Value Monotonicity. This lemma fills in the mismatch that emerges when (non-value) 
expressions in the source language elaborate to values in the target language. Informally, 
if a source expression e elaborates to a target value W, then e evaluates (after potentially 
multiple steps) to a value v that is related to the target value W with an elaboration relation 
under the same type. Furthermore, all expressions on the path to the target value v elaborate 
to the same value and get assigned the same type. 
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► Lemma 1 (Value Monotonicity). //F h e :: W, then there exists v 

(1) e — V 

(2) V'rv :: W 

(3) Vi s.t. e —ei . r h Ci :: W 

Proof. The first two parts are handled similarly to Dunfield’s [10] Lemma 11. The last part 
is proved by induction on the length of the path e —>* e^. Details of this proof can be found 
in the extended version of this paper [30]. ◄ 

The reverse of the above lemma also comes in handy. Namely, given a value v that 
elaborates to an expression M and gets assigned the type A, there exists a value in the target 
language W, such that v elaborates to W and get assigned the same type A. 

► Lemma 2 (Reverse Value Monotonicity). //Thu:: A^ M, then exists W M —W 
and r h u :: A^ W. 

Proof. Similar to proof of Lemma 1. ◄ 

This is an interesting result as it establishes that different derivations may assign the 
same type to a term and still elaborate it to different target terms. For example, one can 
assume derivations that consecutively apply the intersection introduction and elimination 
rules. It’s easy to see that the same value v can be used in the following elaborations: 


• hu :: AiAA 2^ {Wi,W2) 

• hu :: AihA2^ (proji(VFi, ILV), proj2(lFi, IT 2 )) 

'-V-' 

M 

Lemma 2 guarantees it will always be the case that M —>■* (Wi,lF 2 )- It is up to the 
implementation of the type-checking algorithm to produce an efficient target term. 

Primitive Semantics. To connect the failure of the DEAD-casts with source programs getting 
stuck, we assume that the primitive constants are well defined for all the values of their input 
domain but not for DEAD-cast values. This lets us establish that primitive operations c are 
invariant to elaboration. Hence, a source primitive application gets stuck iff the elaborated 
argument is a DEAD-cast. The forward version of this statement is the following assumption. 

► Assumption 1 (Primitive constant application). If (1) • h c :: A — c, (2) • h u :: A^ W, 
and (3) W ^ DEAD.^(-), then (i) c v — >■ |c](t>), (ii) c W —>■ |c](VF), and (hi) • h |c](u) :: 
B^ Icl(IF). 

Substitution lemma. As it typical in these cases, the proof of soundness requires a form of 
substitution lemma. 

► Lemma 3 (Substitution). If F, x : A h e :: A'^ M and Thu:: A’-a W then T h \v/x\ e :: 
A'-^ [W/x] M. 

Proof. Similar to Dunfield’s substitution proof [10] (Lemma 12). ◄ 

The first consistency result is the analogue of Dunfield’s Consistency Theorem [10] and 
states that the elaboration produces terms that are consistent with the source in that each 
step of the target is matched by a corresponding step of the source. Hence, behaviors of the 
target under-approximate the behaviors of the source. 
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► Theorem 4 (Consistency). If ■ \- e :: M and M — > M' then there exists e' such that 

e — e' and - he':: M’ . 

Proof. The proof of this theorem is by induction on the derivation -he:: M, adapting 

the proof scheme given by Dunfield [10], and using Lemma 1. Details of this proof can be 
found in the extended version of this paper [30]. ◄ 

While this suffices to prove soundness - intuitively if the target does not “go wrong” then 
the source cannot “go wrong” either ~ it is not wholly satisfactory as a trivial translation that 
converts every source program to an ill-typed target also satisfies the above requirement. So, 
unlike Dunfield [10], we establish a completeness result stating that if the source term steps, 
then the elaborated program will also eventually step to a corresponding (by elaboration) 
term. Theorem 15 declares that behaviors of the elaborated target over-approximate those of 
the source, and hence, in conjunction with Theorem 14, ensure that the source “goes wrong” 
iff the target does. 

► Theorem 5 (Reverse Consistency), //-he:: A^ M and e —e' then there exists M' 
such that -he':: A’-^ M' , and M —>■+ M'. 

Proof. Similar to the proof of Theorem 14, using adapted versions of the lemmas used by 
Dunfield [10] and Lemma 2. Again, details can be found in the accompanying report [30]. ◄ 

[~T1 Phase 2: Verify 

At the end of the first phase, we have elaborated the source with value based overloading 
into a classically well-typed target with conventional typing features and DEAD-casts which 
are really assertions that explicate the trust assumptions made to type the source. Thanks 
to Theorems 14 and 15 we know the semantics of the target are equivalent to the source. 
Thus, to verify the source, all that remains is to prove that the target will not “go wrong”, 
that is to prove that the DEAD-casts are indeed never executed at run-time. 

One advantage of our elaboration scheme is that at this point any program analysis 
for ML-like languages {i.e. supporting products, sums, and first class functions) can be 
applied to discharge the DEAD-cast [8]: as long as the target is safe, the consistency theorems 
guarantee that the source is safe. In our case, we choose to instantiate the second phase with 
refinement types as they: (1) are especially well suited to handle higher-order polymorphic 
functions, like minindex from Figure 1, (2) can easily express other correctness requirements, 
e.g. array bounds safety, thereby allowing us to establish not just type safety but richer 
correctness properties, and, (3) are automatically inferred via the abstract interpretation 
framework of Liquid Typing [23]. Next, we recall how refinement typing works to show how 
DEAD-cast checking can be carried out, and then present the end-to-end soundness guarantees 
established by composing the two phases. 

5.1 Refinement Type-checking 

We present a brief overview of refinement typing as the target language falls under the scope 
of existing refinement type systems [18], which can, after accounting for DEAD-casts, be reused 
as is for the second phase. Similarly, we limit the presentation to checking; inference follows 
directly from Liquid Type inference [23]. Figure 9 summarizes the refinement system. The 
type-checking judgment is G h M :: T, where type environment G is a sequence of bindings of 
variables x to refinement types T and guard predicates, which encode control flow information 
gathered by conditional checks. As is standard [18] each primitive constant c has a refined 
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Refined Typechecking 


Gh M :: T 


GhM::Ti G h Ti C T 2 

R-Sub —--- - -- 

G h M :: T 2 


R-Cst 

G h c :: ty_c 


x-.T a G 

R-Var- 

G h a: :: sngl(T, x) 


GhMi::Ti G,x-.Tx^ v.T^ 

R-Let - 

G h let a: = Ml in M 2 :: 


R-If 

GhM::Bool G,MhMi::r G,^MhM 2 ::T 


G h M ? Ml : M 2 :: T 


R-Lam 

G,a: : T^;Gh M :: T 
G h \x.M v.T^^T 


R-App 

G^ GI-M2::T, 

G h Ml M 2 :: [M2/a;] T 


R-Pair 

Vfc€{l,2}.GhMfc::Tfc 
Gh (Mi,M 2) :: Ti x T2 


R-Proj 

G h M :: Ti X r2 
G h projfcM :: Tk 


R-Inj R-Case 

G\- M -.-.Tk G h M :: Ti+Ta G, a;i : Ti h Mi :: T G, a;2 : T 2 h M 2 :: T 

G h injj, M :: T 1 +T 2 G h case M of inji xi => Mi | inj 2 a :2 => M 2 :: T 


Refinement Subtyping 


G h Ti C T 2 


C-Base 


Valid(|Gl A IpI ^ jp'l) 
Gh {z/:B iV} Q {i':M \p'} 


GhT'QT^ G, a: :T' h T C T' 

C-Fun -- — --—-- , 

G h (a; : T^) ^ T C (a: : T^) ^ T' 


M Figure 9 Refined Type-checking 


type ty_c, and a variable x with type T is typed as sngl(T, x) which is :]B | = x} if T is 

a basic type B and T otherwise. 

Checking DEAD-casts. The refinement system verifies DEAD-casts by treating them as special 
function calls, i.e. discharging them via the application rule R-App. Formally, DEADai^(M) 
is treated as call to: 

DEADauj :: Bot([A]) -A Bot([R]) 

The notation [•] denotes the elaboration of Ay types to types [10]: 

[B] A B [A A R] = [A] X [B] [A V R] = [A]-E[R] [A ^ R] A [A] ^ [R] 

The meta-function Bot(r) = Tx(T, false) where: 

Tx(B, r) A {i/:B I r} Tx(5'-Er, r) A Tx(5, r)-ETx(r, r) 

Tx(S ->• T, r) A Tx( 5', ^r) Tx(r, r) Tx(5' x T, r) A Tx(5, r) x Tx(r, r) 

Returning to rule R-App for DEAD-casts and inverting, expression M gets assigned 
a refinement type T. For simplicity we assume this is a base type B. Due to R-Sub 
we get the sub typing constraint: Gh {j^:B \ p} C {i/:B | false}, which generates the VC: 
Valid(|G] A |p] ^ |/afoe]). This holds if the environment combined with the refinement 
in the left-hand side is inconsistent, which means that the gathered flow conditions are 
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infeasible, hence dead-code [18]. Thus, the refinements statically ensure that the specially 
marked DEAD values are never ereated at run-time. As only DEAD terms cause execution to 
get stuck, the refinement verification phase ensures that the source is indeed type safe. 

Conditional Checking. R-If and R-Case check each branch of a conditional or case 
splitting statement, by enhancing the environment with a guard (M or ^M) or the right 
binding {x:Ti or x:T 2 ), that encode the boolean test performed at the condition, or the 
structural check at the pattern matching, respectively. Crucially, this allows the use of “tests” 
inside the code to statically verify DEAD-casts and other correctness properties. The other 
rules are standard and are described in the refinement type literature. 


Correspondence of Elaboration and Refinement Typing. The following result establishes 
the fact that the type A assigned to a source expression e by elaboration and the type T 
assigned by refinement type-checking to the elaborated expression M are connected with 
the relation: [A] — ||r||, where ||T|| is merely a (recursive) elimination of all refinements 
appearing in T. The notation [F] = ||G|| means that for each binding a;: A G F there exists 
x:T G G, such that [A] = ||T||, and vice versa. 

► Lemma 6 (Correspondence). //F h e :: A^M, G \- M :: T and [F] = ||G||, then 
[A] = \\T\\. 

Proof. By induction on pairs of derivations: F h e :: A^ M and G h M :: T. Details of this 
proof can be found in the extended version of this paper [30]. ◄ 

The target language satisfies a progress and preservation theorem [18]: 

► Theorem 7 (Refinement Type Safety). // • h M : T then either M is a value or there 
exists M' such that M —> M' and ■ h M' : T. 

Proof. Given by Vazou et al. [29] for a similar language. ◄ 


5.2 Two-Phase Type Safety 

We say that a source term e is well two-typed if there exists a source type A, target term M 
and target (refinement) type T such that: (1) -he :: M, and, (2) • h M :: T. That is, e 

is well two-typed if it elaborates to a refinement typed target. The Consistency Theorems 14 
and 15, along with the Safety Theorem 7, yield end-to-end soundness: well two-typed terms 
do not get stuck, and step to well two-typed terms. 

► Theorem 8 (Two-Phase Soundness). If e is well two-typed then, either e is a value, or 
there exists e! such that: 


(1) (Progress) e —> e' 

(2) (Preservation) e! is well two-typed. 

Proof. By induction on pairs of derivations: F h e :: A^ M and G \- M :: T. Details are to 
be found in the extended version of this paper [30]. ◄ 


6 


Related Work 


We focus on the highlights of prior work relevant to the key points of our technique: static 
types for dynamic languages, intersections and union types, and refinement types. 
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Types for Dynamic Functional Languages. Soft typing [5] incorporates static analysis to 
statically type dynamic languages: whenever a program cannot be proven safe statically, 
it is not rejected, but instead runtime checks are inserted. Henglein and Rehof [17] build 
up on this work by extending soft typing’s monomorphic typing to polymorphic coercions 
and providing a translation of Scheme programs to ML. These works foreshadow the notion 
of gradual typing [24] that allows the programmer to control the boundary between static 
and dynamic checking depending on the trade-off between the need for static guarantees 
and deployability. Returning to purely static enforcement, Tobin-Hochstadt et al. [27, 28] 
formalize the support for type tests as occurrence typing and extend it to an inter-procedural, 
higher-order setting by introducing propositional latent predicates that reflect the result of 
tests in Typed Racket function signatures. 


Types for Dynamic Imperative Languages. Thiemann [26] and Anderson et al. [1] describe 
early attempts towards static type systems for JavaScript, and Furr et al. [15] present DRuby, 
a tool for type inference for Ruby scripts. However, these systems do not handle value-based 
overloading (like TypeScript, DRuby allows overloaded specifications for external functions). 
Flow typing [16] and TeJaS [19] account for tests using flow analysis, bringing occurrence 
typing to the imperative JavaScript setting, but, unlike our approach, they restrict themselves 
to a fixed set of type-testing idioms {e.g. typeof), precluding general value-based overloading 
e.g. as in reduce from Figure 1. 


Logics for Dynamic Languages. The intuition of expressing subtyping relations as logical 
implication constraints and using SMT solvers to discharge these constraints allows for a more 
extensive variety of typing idioms. Bierman et al. [3] investigate semantic subtyping in a first 
order language with refinements and type-test expressions. In nested refinement types [7], 
the typing relation itself is a predicate in the refinement logic and a feature-rich language 
of predicates accounts for heavily dynamic idioms, like run-time type tests, value-indexed 
dictionaries, polymorphism and higher order functions. While program logics allow the use 
of arbitrary tests to establish typing, the circular dependency between values and basic types 
leads to two significant problems in theory and practice. First, the circular dependency 
complicates the metatheory which makes it hard to add extra (basic) typing features {e.g. 
polymorphism, classes) to the language. Second, the circular dependency complicates the 
inference of types and refinements, leading to significant annotation overheads which make 
the system difficult to use in practice. In contrast, two-phase typing allows arbitrary type 
tests while enabling the trivial composition of soundness proofs and inference algorithms. 


Intersection and Union Types. Central to our elaboration phase are intersection and union 
types: Pierce [21] indicates the connection between unions and intersections with sums and 
products, that is the basis of Dunfield’s elaboration scheme [10] on which we build. However, 
Dunfield studies statie source languages that use explieit overloading via a merge operator [22] . 
In contrast, we target dynamic source languages with implicit value based overloading, and 
hence must account for “ill-typed” terms via DEAD-casts discharged via the second phase 
refinement check. Castagna et al. [6] describe a A&-calculus, where functions are overloaded 
by combining several different branches of code. The branch to be executed is determined at 
run-time by using the arguments’ typing information. This technique resembles the code 
duplication that happens in our approach, but overload resolution {i.e. deciding which branch 
is executed) is determined at runtime whereas we do so statically. 
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Refinement Types. DML [31] is an early refinement type system composing ML’s types 
with a decidable constraint system. Hybrid type checking [18] uses arbitrary refinements over 
basic types. A static type system verifies basic specifications and more complex ones are 
defered to dynamically checked contracts, since the specification logic is statically undecidable. 
In these cases, the source language is well typed (ignoring refinements), and lacks intersections 
and unions. Our second phase can use Liquid Types [23] to infer refinements using predicate 
abstraction. 

[Y] Conclusions and Future Work 

In this paper, we introduce two-phased typing, a novel framework for analyzing dynamic 
languages where value-based overloading is ubiquitous. The advantage of our approach over 
previous methods is that, unlike purely type-based approaches [28], we are not limited to a 
fixed set of tag- or type- tests, and unlike purely program logic-based approach [7], we can 
decouple reasoning about basic typing from values, thereby enabling inference. 

Hence, we believe two-phased typing provides an ideal foundation for building expressive 
and automatic analyses for imperative scripting languages like JavaScript. However, this is 
just the first step; much remains to achieve this goal. In particular we must account for the 
imperative features of the language. We believe that decoupling makes it possible to address 
this problem by applying various methods for tracking mutation and aliasing [32] in the first 
phase, and we intend to investigate this route in future work to obtain a practical verifier for 
TypeScript. 
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Appendix 

We now provide detailed versions of the proofs mentioned in the main part of the paper. 
This part reuses the definitions of § 3, § 4 and § 5, and is structured in three main sections: 

H Assumptions (A) 

H Lemmas (B) 

B Theorems (C) 

Sections A and B build up to the main results: 

H Consistency and Reverse Consistency Theorems (14, 15) 

H Two-phase Safety Theorem (16) 

For the remainder of the document we are going to use the plain version of the elaboration 
relation, i.e. without mode annotations: 

The:: 

The annotations on the judgment merely determine which rules are available at type-checking. 
The majority of the proofs below involve induction over the elaboration derivation, which is 
fixed once type-checking is complete, so the annotations can be safely ignored. 

In certain lemmas the reader is referred to Dunfield’s techniques from his work on the 
elaboration of intersection and union types [10]. The proofs there refer to a language similar 
but not exactly the same as ours. The main proof ideas, however, hold. 


A 


Assumptions 


► Assumption 1 (Primitive Constant Application). If 

(1) • h c :: A — c, 

(2) -ha :: A^ IF, 

(3) W ^ DEAD.m(-), 

then 

m cv —^ |c](u) 

- [cl(IF) 

- -hlcKu) -.-.B^lcUW) 

► Assumption 2 (Lambda Application). If 

(1) • h Xx.e :: B^ Xx.M, 

(2) -ha :: A^ IF, 
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(3) W ^ DEAD.j^(-), 
then 

H (Aa;.e) v —>■ [v/x] e 
- {Xx.M) W —^ ^jx] M 
► Assumption 3 (Canonical Forms). 

(1) If r h \x.e :: A —> W then 

- W = Xx.M for some M, or 

. W = DEAD.j^^B(Vh') for some W' 

(2) If r h c :: W then 

_ = c, or 

. W = DEAD.^(W^') for some W' 


B 


Auxiliary lemmas 


► Lemma 1 (Multi-Step Source Evaluation Context). If e —>■* e' then E[e] —>* E[e']. 

Proof. Based on Lemma 7 of Dunfield’s elaboration [10]. ◄ 

► Lemma 2 (Multi-Step Target Evaluation Context), h If M — >* M' thenE[M] — >* S[M'] 
^ If M — M' then £[M] — £[M'] 

Proof. Similar to proof of Lemma 1. ◄ 

► Lemma 3 (Unions/Injections). //L h e :: V A 2 ^ injj, M then L h e :: Ak^ M. 

Proof. Based on Lemma 8 of Dunfield’s elaboration [10]. ◄ 

► Lemma 4 (Intersections/Pairs). IfT \- e :: Ai A ^ 2 ^ (Mi, M 2 ) then there exist e[ and e '2 
such that: 

(1) Cl —>■* e'l and T h e'l :: Ai^ Mi 

( 2 ) 62 —>■* 62 and L h 62 :: ^ 2 ^ M 2 

Proof. Based on Lemma 9 of Dunfield’s elaboration [10]. ◄ 

► Lemma 5 (Beta Reduction Canonical Form). If 

(1) ■ h Aa:.e y.A^B^ Wi, 


(2) ■hv2:: A-a W 2 , 


(3) (Xx.e) V 2 


[v 2 /x] e 
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Then Wi = \x.M for some M. 

► Lemma 6 (Primitive Reduction Canonical Form). If 

(1) • he :: A ^ Wi 
f2j -hv :: W 2 , 

(3) cv —^ |c|(i;) 

Then: 

- hhi = c 

- hh2 ^ DEAD.m(-) 

► Lemma 7 (Conditional Canonical Form). If 

(1) -he:: Bool^ W, 

(2) • h Cl :: Mi and • h 62 :: A^ AI 2 , 

(3) c ? ei : 62 —> Bk 
Then: 

H k=l^c = W= true. 

H k = 2^c = W= false. 

► Lemma 8 (Value Monotonicity). //The:: A^ W , then there exists v ■ 

(1) e —V 

(2) T'rv :: W 

(3) V z .; e —e* . T h e, :: W 

Proof. Parts (1) and (2) of the lemma has been proved by Dunfield [10] for a similar language, 
so here we are just going to prove part (3). 

We will show this by induction on the length i of the path: e —>* e^. 

• For the case z = 0: e = e^, so it trivially holds. 

• Suppose it holds for i = k, i.e. for e —>■* eu, it holds that: 

rhefe::^^W ( 2 . 1 ) 

We will show that it holds for z = fc -F 1, i.e. for Cfc+i such that: 

B-k t Bk+l (^■^) 

We will do this by induction on the derivation (2.1), but limit ourselves to the terms Bk 
that elaborate to values: 
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[> Cases T-Cst, T-Var, T-AI, T-Lam: For these cases, term is already a value, so 
doesn’t step. 

[> Case T-VI (assume left injection - the case for right injection is similar): 

r h Cfc :: Ai^ W h Ai V A 2 
T \- Ck w AiM A2^ injj W 

By inversion: 

r h efe :: ^1=^ W 

By i.h., using (2.2): 

r h Cfe+i :: Ai^ W 

Applying rule T-VI on the latter one: 

r h Cfc+i :: Ai V ^ 2 ^ inJi W 

◄ 


► Lemma 9 (Reverse Value Monotonicity). IfThv:: A^ M , then exists W s.t.: M —>■* W 
and r h u :: A^ W. 

Proof. Similar to proof of Lemma 8. ◄ 

► Lemma 10 (Substitution). Ifr,x:A he:: M and F h u :: A^ W then F h \v/x\ e :: 

A'-a [W/x] M. 

Proof. Based on Lemma 12 of Dunfield’s elaboration [10]. ◄ 

► Corollary 11 (Target Multi-step Preservation). If ■ \- M :: T and M —>* M' then 
• h M' :: T. 

Proof. Stems from Theorem 7 from main paper. ◄ 

► Corollary 12 (DEAD-cast Invalid). • 1 /DEADalb (AT) :: T 

► Lemma 13 (Correspondence). 

yT,e,A,M,G,T . F h e :: A-a M (0 .1) 

A GhM::T (0.2) 

A [F] = ||G|| (0.3) 

^ [A] = ||r|| 

Proof. We prove this by induction on pairs T-Rule/K-Rule of derivations: 


F h e :: A-a M 
G\- M -.-.T 
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• Case T-Cst/R-Cst: 

The:: ty_c^ c 
G \- c :: {i^: ty_c | i/ = Const(c)} 

Meta-function sngl operates entirely on the refinement so it holds that: 

||{j^:ty_c I = Const(c)}|| = ||ty_c|| 

Also, it holds that: 

[ty_c] = ||ty_c|| 

• Case T-Var/R-Var: 

x:AgT x:T€G 

r h X :: X G \- x :: sngl(T, x) 

By inversion: 

x: A G r 
x:r G G 

If X is bound multiple times in F and G, we assume the we have picked the 
instances from each environment. 

By (0.3) we have that: 

[r(x)] = ||G(x)|| 

Also meta-function sngl operates entirely on the refinement so it holds that: 

||T|| = ||sngl(T,x)|| 

By (2.1), (2.2) and (2.3) it holds that: 

[A] = ||sngl(r,x)|| 

• Case T-Let/R-Let: 

From the first premise of the implication: 

r h Cl :: Ai'-)- Ml r,x:Ai h 62 :: A2^ M2 

r h let X = Cl in 62 :: A2‘->' let x = Mi in M2 

By inversion: 

F h ei :: Ai'— > Mi 
F,x:Ai h 62 :: A2‘— > M2 

From the second premise of the implication: 

Gl-Mi::Ti G,x:Ti h M2 :: T2 
G h let X = Ml in M2 :: T2 

By inversion: 


( 2 . 1 ) 

( 2 . 2 ) 

correct 


(2.3) 


(3.1) 

(3.2) 


Gh Ml :: Ti 
G,x:ri I-M 2 ::T2 


(3.3) 

(3.4) 
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By i.h. on (0.3), (3.1) and (3.3): 


II 

(3.5) 

By (0.3) and (3.5): 


[F,a::Ai] = ||G,a::ri|| 

(3.6) 

By i.h. on (3.2), (3.4) and (3.6): 

[^ 2 ] = 11^211 


Case T-If/R-If: Similar to previous case. 


Case T-AI/R-Pair: 

From the first premise of the implication: 


\/k e {1,2} .Thv :: Ak^Wk 

T^v:: Ai A A 2 -A {Wi,W 2 ) 


By inversion: 


Vfc G {1,2} . F h :: Afc-A Wk 

(5.1) 

From the second premise of the implication: 


VfcG{l,2}.GhVFfe::Tfc 

Gh{Wi,W 2 ) :: Ti x T 2 


By inversion: 


VfcG{l,2}.Gl-lUfc::Tfe 

(5.2) 

By i.h. on (0.3), (5.1) and (5.2): 


VfcG {1,2} . [Ak] = llTfell 

(5.3) 


Using properties of [•] and H-H: 

[Ai A A2] = [Ai] X [A2] = llTill X IIT2I! = llTi X T^W 

• Case T-AE/R-Proj: Straightforward based on earlier cases. 

• Case T-Lam/R-Lam: Straightforward based on earlier cases. 

• Case T-App/R-App: Straightforward based on earlier cases. 

• Case T-VI/R-Inj: Straightforward based on earlier cases. 

• Case T-VE/R-Case: 

From the first premise of the implication: 

r, a:i: Ai h E[xi] :: Mi 

F h eg :: Ai V A2‘—^ Mq F,a:2:A2 F ii/[a:2] :: M 2 

F h E[eo] :: case Mq of inj^ xi Mi \ inj2 X2 M2 
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By inversion: 


F F cq :: Ai V A2^ — y Mq 

(10.1) 

F, xi'.Ai h E[xi] :: Mi 

(10.2) 

F, 0:2 : A 2 F E[x2] :: M 2 

(10.3) 


From the second premise of the implication: 

Gh Mo:: T 1 +T 2 G, : Ti h Mi :: T G, ^2 : Ta h M2 :: T 
G h case Mq of inji x\ ^ Mi | inj 2 X 2 => M 2 :: T 

By inversion: 


G F Mo :: T 1 +T 2 

(10.4) 

G,xi 

: Ti F Ml : 

: T 

(10.5) 

G, X 2 

: T 2 F M 2 : 

: T 

(10.6) 


By i.h. on (0.3), (10.1) and (10.4): 

[yii VA 2 ] = ||ri+r2|| 

From properties of type elaboration and refinement types: 

[^1 V A 2 ] = [Ai]-|-[^2 ] 

||Ti+r2|| = ||Ti|| + ||T2|| 


The right-hand side of the last two equations are tagged unions, so it is possible to match 
the consituent parts by structure: 

[Ai] = ||Ti|| and [4l2] = |lr 2 || 

Combining the last equation with (0.3): 

[F,a::Ai] = ||G,x:ri|| (10.7) 

[T,x:A2] = \\G,x:T2\\ (10.8) 

By i.h. on (10.2), (10.5) and (10.7) (or (10.3), (10.6) and (10.8)): 

[B] = ||T|| 

• Case T-_L/R-App: 

From the first premise of the implication: 

F h e :: A^ M TAG(A) C TAG(R) = 0 
F h e :: DEAD^(M) 

From the second premise of the implication: 

G h DEADa^ :: Bot([A]) ^ Bot([R]) G h M :: S' 

G h DEADau3(M) :: [M/x] Bot([R]) 

The result type of the last derivation can also be written as: 


[M/x] Bot([R]) = Bot([R]) 

Because after the application of Bot(-) all original refinement get erased. Also, after 
removing the refinements: 


◄ 


||Bot([i?])|| = [R] 
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I C I Theorems 

► Theorem 14 (Consistency), //-he:: M and M —)■ M' then there exists e! such that 

e — >* e' and -he':: M' . 

Proof. By induction on the derivation -he:: A^ M 

• Cases T-Cst, T-Var, T-AI, T-AE and T-Lam: 

The respective target expression does not step. 

• Case T-Let: 

• h Cl :: Ml x:Ai h 62 :: ^2^ AI2 

■ h let a; = Cl in 62 :: A2^ let x = Mi in M2 

By inversion: 

• h ei :: Mi (2.1) 

x:Ai h 62 :: ^ 42 ^ M 2 (2-2) 

Cases on the form of M —M': 


[> Subcase: 

Ml —^ M'l 

let X = Ml in Mi —> let x = M[ in M2 

By inversion: 

Ml —^ M'l 

By i.h. on (2.1) and (2.3) there exists e'l 

ei —Cl 

• h e'l :: Ai^^ M( 

Applying rule T-Let on (2.2) and (2.4): 

• h let X = e'l in 62 :: ^2^ let x = M( in AI2 

t> Subcase: 

let x = Wi in M2 —[VEi/a:] M2 

Equation (2.1) becomes: 

• h ei :: Ai^^ Wi 

By Lemma 8 there exists Vi such that: 

ei —vi 

• b Vi :: Ai^ — ^ Wi 

By Lemma 1 using (2.5) on E = let a; = () in 62 : 

let a: = ei in 62 —>■* let x = vi in 62 
By Lemma 10 on (2.2) and (2.6), there exists e' = [ui/a;] e 

let x = vi in 62 — [vi/x] 62 
■ ^ ['*^1/^] 62 •• A2‘— > \Wi/x\ AL2 


(2.3) 


(2.4) 


(2.5) 

( 2 . 6 ) 
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• Case T-If: 

• h Cc :: Bool^ M Vz S {1,2} . • h Ci :: Ali 

* l~ Cc ? : 62 :: A^— y lUc 2 ilfi : A^2 

By inversion: 

• h Cc :: Bool^ 

• h ei :: A'-)- Mi 

• 1-62 :: M 2 

Cases on the form of M —> M': 

0 Subcase: 

M, ^ M' 

Me ? Ml : M2 —M^ 1 Ml : M2 

By inversion: 

Me^M' 

By i.h. using (3.1) and (3.4) there exists e} such that 

Sc ^ Cc 

•he}:: Bool^ M} 

Applying rule T-If on (3.5), (3.2) and (3.3) we get: 

• h e} ? ei : 62 :: M} ? Mi : M 2 

0 Subcase: 

true ? Ml : M2 —> Mi 

Equation 3.1 becomes: 

• h Cc :: Bool^ true 
By Lemma 8 there exists Vc such that: 

Cc —Vc 

• h Uc :: Bool^ true 

The only possible case for (3.7) to hold is: 


Vc = true 

By applying Lemma 1 using (3.6) on E ={) 1 ei : 62 : 

Cc ? 61 : 62 —true ? ei : 62 
By E-Cond-True: 

true ? ei : 62 —ei 

So there exists e' = ei, such that e —>■* e' and by (3.2) it holds that: 

•he':: Mi 


(3.1) 

(3.2) 

(3.3) 


(3.4) 


(3.5) 


(3.6) 

(3.7) 
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[> Subcase: 


This case is similar to 

• Case T-App: Similar to 

• Case T-VI: 


false ? Ml : Mi —> M2 
the previous one. 

proof given hy Dunfield [10] in proof of Theorem 13. 


•he:: ^ Mq h Ai V A2 

• h e :: Ai V A2^ injA Mq 


By inversion: 


•he:: A^^ Mq 
h Ai V A2 

The only possible case for M —)• M' is: 


Mq 


M'q 


M'q 


injfe Mq —inj^, M] 

By inversion: 

Mq 

By i.h. using (5.1) and (5.3) there exists an e' such that: 


h eA: A'I'q 


By T-VI on (5.5) and (5.2): 


h e' :: Ai V ^2=— injj. M] 


(5.1) 

(5.2) 


(5.3) 


(5.4) 

(5.5) 


• Case T-VE: 

Xi'.Ai h E[xi] :: Mi 

• h eo :: Ai V A 2 ^ Mq X 2 'A 2 h il/[a:: 2 ] :: M2 

■ h if[eo] :: case Mq of inji xi => A'h \ inj2 X2 ^ M2 

By inversion: 

( 6 . 1 ) 
( 6 . 2 ) 
(6.3) 


[> Subcase: 

_ Mq^ M'q _ 

case Mq of inJi xi => Mi \ inj2 0:2 => M2 — 
case M'q of inji I 11^12 ^2 M2 


• h eo :: Ai V A 2 ^— ^ Mq 
a;i:Ai h i?[a;i] :: Mi 

a: 2 :A 2 h E[x 2 ] B^ AI2 

Cases on the form of M —)• M': 
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By inversion: 

Mo 

By i.h. using (6.1) and (6.4) there exists e'g such that 

Co ->■ Cq 

• h Bq :: Ai V Mq 

Applying T-VE on (6.6), (6.2) and (6.3); 

• h EIcq] :: Ai^ case Mg of injd xi ^ Mi \ inj2 X2 => M2 
By applying Lemma 2 using 6.5: 

E[eo] E[e'o] 

0 Subcase: 

case injd W of inji Xi => Mi | inj2 X2 M2 — [lE/a:i] Mi 
Equation (6.1) becomes: 

• h eo :: Ai V ^ 2 ^ inji W 

Applying Lemma 8 on (6.7), there exists Vq such that: 

Co —Vo 

• h uq :: Ai V ^ 2 ^ inji W 
By applying Lemma 3 on (6.9): 

• b Vq :: Ai^ — ^ TE 

Applying Lemma 10 on (6.2) and (6.10): 

• I- [vo/xi] E[xi] :: [W/xi] Mi 

Or, after the substitutions^: 

• h E[vo] :: Ai-^ [W/xi] Mi 
Applying Lemma 1 on (6.8): 

E[eo] E[vo] 

0 Subcase: 

case inj2 W of inji ^1 I 11^12 ^2 => M2 —> [lE/a:2] M2 
is similar to the previous one. 


(6.4) 


(6.5) 

( 6 . 6 ) 


(6.7) 

( 6 . 8 ) 
(6.9) 

( 6 . 10 ) 

( 6 . 11 ) 


Variable xi is only referenced in the “hole" of the evaluation context E[xi\. 


3 
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• Case T-_L: 

■he:: M TAG(A) n TAG(B) = 0 

■he:: DEAD^(M) 

By inversion: 

■he:: M ( 7 . 1 ) 

TAG(A) n TAG(B) = 0 ( 7 . 2 ) 

The only possible step here is: 

M —> M' 

DEADaib{M) —> DEADaib(M') 

By inversion: 

M —> M' (7.3) 

By i.h. using (7.1) and (7.3) there exists e! such that: 
e —>■* e' 

•he':: M' (7.4) 

By applying T-_L on (7.4) and (7.2): 

•he':: DEADau3(M') 


◄ 

► Theorem 15 (Reverse Consistency), //-he:: M and e —> e! then there exists M' 

such that - he':: A^ M' , and M —:•+ M'. 

Proof. By induction on the derivation -he:: A^ A'l 

• Cases T-Cst, T-Var, T-AI, T-Lam: 

The respective source expression does not step. 

• Case T-Let: 

• h ei :: Ai^ Mi a;:Ai h e2 :: Ai^ M 2 

- ( 2 . 1 ) 

• h let X = Cl in 62 :: A 2 '-?^ let x = Mi in M 2 

By inversion: 


• h ei :: Mi 

x: Ai h e2 :: A2^ M 2 


( 2 . 2 ) 

(2.3) 


Cases on the form of e 


[> Subcase: 



let X = ei in 62 —> let x = e'l in 62 
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By inversion: 

ei —^ e'l 

By i.h. using (2.2) and (2.4): There exists M[ such that: 

• h e'l :: M[ 

Ml — M[ 

Applying rule T-Let on (2.3) and (2.5): 

• h let X = e'l in 62 :: A 2 ‘^ let x = M[ in M 2 
By Lemma 2 on (2.6) we get: 

M — M' 


0 Subcase: 


let X = vi in 62 


[Vi/x] 62 


Equation (2.2) becomes: 

• h ui :: Ai^ Ml 

By Lemma 9 on (2.7) there exists Wi such that: 

Ml — Wi 
■ h vi :: Ai^ Wi 


By Lemma 2 using (2.8) on £ = let a; = ( ) in M 2 : 
let X = Ml in M 2 — >* let x = Wi in M 2 


By TE-Let: 

let X = Wi in M 2 —[lEi/a;] M 2 
By (2.10) and (2.11): 

let X = Ml in M 2 —[VEi/a:] M 2 
And by Lemma 10 on (2.3) and (2.9): 

• h [vi/x] 62 :: A 2 ^ [VEi/a:] M 2 
• Case T-If: 

‘ h Cc Bool^— y Ad \/i G {1, 2} . * b :: — y 

• h Cc ? 61 : 62 :: A'-)- Ale ? Mi : M 2 
By inversion: 

• h Oc :: Bool^ M^ 

• h 61 :: A'-)- Ml 

• h 62 :: A'-)- M 2 


(2.4) 

(2.5) 

( 2 . 6 ) 


(2.7) 

( 2 . 8 ) 

(2.9) 

( 2 . 10 ) 

( 2 . 11 ) 


(3.1) 


Cases on the form of e 


(3.2) 

(3.3) 

(3.4) 
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[> Subcase: 


Be ei : 62 


61 : 62 


By inversion: 

6 c ^ 6g 

By i.h. using (3.2) and (3.5) there exists M' such that: 

• h e(, :: Bool^ M'^ 

Me —M^ 


By Lemma 2 using (3.7): 

Me ? Ml : M2 —M' ? Ml : M2 

Applying rule T-If on (3.6), (3.3) and (3.4) we get: 

• h e(, ? 61 : 62 :: M' ? Mi : M2 


[> Subcase: 

true ? Cl : 62 —ei 

Equation 3.2 becomes: 

• h true :: Bool^ Me 

By Lemma 9 there exists We such that: 

Me W, 

■ h true :: Bool^ We 

By Lemma 2 using (3.10): 

Me ? Ml : M2 —lEe ? Ml : M2 

By Lemma 7 on (3.11), (3.3), (3.4) and (3.8): 

Wc = true 

By TE-Cond-True: 

true ? Ml : M2 —)■ Mi 
By (3.12) and (3.14): 

Me ? Ml : M 2 —Ml 

Combining with (3.3) we get the wanted relation. 

> Subcase: 

false ? 61 : 61 —62 

Similar to the previous case. 


(3.5) 

(3.6) 

(3.7) 


(3.8) 

(3.9) 

(3.10) 

(3.11) 

(3.12) 

(3.13) 

(3.14) 
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• Case T-AE: Similar to earlier eases. 

• Case T-App: 

• h ei :: A —>■ Mi ■ \- €2 A^ M2 

• h ei 62 :: Mi M2 

By inversion: 

• h 61 :: A —> B^ Mi 

• 1-62 :: A^ M 2 

Cases on the form of e —> e'\ 


0 Subcase: 



61 62 —> e'l 62 


Similar to eariler eases, e.g. let x = 61 in 62 —> let x = e'l in 62 


0 Subcase: 


By inversion: 

62 —62 



Vl 62 -^ Vi 62 


By Lemma 9 on (5.2) there exists Wi such that: 

Ml — Wi 

* l— Vl :: ^2^ — y Wi 

By Lemma 2 using (5.5): 

Ml M 2 — Wi M 2 

By i.h. using (5.3) and (5.4) there exists M 2 such that: 

M 2 —!•+ M 2 

• h 62 :: A-a M 2 


By Lemma 2 using (5.8) on the target of (5.6): 

Wi M2 —Wi M2 


And combining with (5.7): 

Ml M 2 —Wi M^ 

By rule T-App using (5.2) and (5.9): 


(5.1) 


(5.2) 

(5.3) 


(5.4) 


(5.5) 

(5.6) 


(5.7) 


(5.8) 

(5.9) 


• h Vl 62 :: A-a Wi M' 
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[> Subcase: 


(Ax.Co) V 2 -)■ [v 2 /x\ Co 

By Lemma 9 on (5.2) there exists Wi such that: 

• h Ax.Co :: A —> Wi 

Ml —Wi 

By applying Lemma 2 on M = Mi M 2 given (5.15): 

Ml M2 —Wi M2 
Equation (5.3) is: 

■\- V2 :: M 2 

By Lemma 9 on (5.14), there exists W 2 such that: 

M2 — W2 
■ h V2 :: W 2 

By Lemma 5 on (5.11), (5.16) and (5.10), there is a Mg such that: 

Wi = Ax.Mo 


(5.10) 

(5.11) 

(5.12) 

(5.13) 

(5.14) 

(5.15) 

(5.16) 


So (5.2) becomes: 

• h Ax.eg :: A —>■ Ax.Mg (5.17) 

The only production of (5.17) is by T-Lam: 

h A —>■ B x-.Aheo'.: B^ Mg 
L Ax.eg :: A —^ B^ — y \x.Mq 


By inversion: 


x: A h eg :: B"^ Mg 

By applying Lemma 10 on (5.18) and (5.16) we get: 

(5.18) 

• [v 2 /x\ eg :: [W 2 /X] Mg 

By applying Lemma 2 on M = (Ax.Mg) M 2 given (5.15): 

(5.19) 

(Ax.Mg) M 2 —(Ax.Mg) W 2 

By rule TE-App-2: 

(5.20) 

(Ax.Mg) W 2 [lEa/x] Mg 

By (5.13), (5.20) and (5.21) we get: 

(5.21) 

Ml M 2 -[IE 2 /X] Mg 

By (5.19) and (5.22) we get the wanted relation. 

(5.22) 
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0 Subcase: 

cv —^ |c](u) 

Equations (5.2) and (5.3) become: 

• h c :: A —> Mi 

• h u :: M 2 

By Lemma 9 on (5.24) there exists Wi such that: 

• h c :: A ^ Wi 

Ml Wi 

By Lemma 2 on M = Mi M 2 given (5.27): 

Ml M2 —Wi M2 

By Lemma 9 on (5.25) there exists W 2 such that: 

M 2 W 2 

■ h V :: W 2 


By Lemma 2 on (5.29): 
c M 2 —c W 2 

By Lemma 6 on (5.26), (5.30) and (5.23): 

Wi=c 

W2 ^ dead.m(-) 

So (5.26) becomes: 

■ b c :: A —^ B'^— y c 
So we can apply TE-App-1: 

CW2 [cl (1^2) 

By (5.34), (5.31) and (5.35): 

Ml M2 [cKlEa) 

By assumption 1 using (5.34), (5.33) and (5.30): 

• I- M{v) ■■ [cKlEz) 


• Case T-VI: 


By inversion: 


•he:: Aj,^ M h Ai V A2 
• h e :: Ai V A2‘-> inj^, M 


(5.23) 

(5.24) 

(5.25) 

(5.26) 

(5.27) 

(5.28) 

(5.29) 

(5.30) 

(5.31) 

(5.32) 

(5.33) 

(5.34) 

(5.35) 


•he:: A^^ M 
h Ai V A2 


( 6 . 1 ) 

( 6 . 2 ) 
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By i.h. using (6.1) with e —e', there exists M' such that: 

•he':: M' (6.3) 

M — M' (6.4) 

By Lemma 2 using (6.4): 

injj, M —injj. M' 

Applying T-VI with premises (6.3) and (6.2): 

• h e' :: Ai V ^ 2 ^ injA M' 


• Case T-VE: 

Xi'.Ai h E[xi] :: Mi 

• h eo :: Ai V A2^ Mq X2-A2 h ii/[x 2 ] :: B^ M 2 
■ h E[eo] :: B^ case Mq of injd xi ^ AIi \ inj2 X2 ^ AI2 

By inversion: 

(7.1) 

(7.2) 

(7.3) 


* h Cq :: Ax V A 2 ^— ^ AIq 
h E[xi] :: B^ AIi 
^2:^2 h E[x 2 ] :: B^ AI2 

Cases on the form of e —> e': 


[> Subcase: 


By inversion: 
eo — > b'q 

By i.h. using (7.1) and (7.4): 

• h Cq :: Ax V A 2 ^— y Afo 
Mq —^+ M' 


eo 



(7.4) 


(7.5) 

(7.6) 


Using rule T-VE on (7.5), (7.2) and (7.3): 

• h E[eQ] :: B^ case AI'q of injx xi ^ Mi \ inj 2 X 2 A /2 

Also, applying Lemma 2 on £ = case ( ) of injx Afi | inj 2 X 2 => M 2 using 

(7.6): 

case Mq of injx *1 Afi | inj 2 X 2 => M 2 — 
case Mq of injx Afi | inj2 X 2 => M 2 


[> Subcase: 


eo = vq 


E[vq\ 


(7.7) 

(7.8) 
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Because vq is a value, we can split cases for its type. Without loss of generality we can 
assume that its type is Ai (the same exact holds for A 2 ). This is depicted on the form 
of Mo in equation (7.1), which now becomes (for some Mqi): 


• h ug :: Ai V ^ 2 ^ inji Mqi (^-Q) 

By Lemma 3 on (7.9): 

• h Uq :: Mqi (^-lO) 

By Lemma 9 on (7.10) there exists Wqi such that: 

Moi Woi (7.11) 

• h no :: Woi (7.12) 

By Lemma 9 on (7.9) there exists Wqi^ such that: 

inji Moi inji Woi (7.13) 

• h no :: Ai V ^ 2 ^ inj\ Wqi (7-14) 


Cases for the form of i?[no]: 

- i?[no] = let cc = no in e\ 

The original elaboration judgment becomes: 

cci:h let a: = cci in ei :: Mi 

• h no :: Til V A 2 ^ Mq X 2 -A 2 h let a: = 0:2 in ei :: M 2 

■ h let a: = no in ei :: B^ case Mq of inj;^ xi => Mi \ inj 2 X 2 => M 2 

By inversion: 


• b no :: Ai V ^ 42 ^ — ^ Mq 

xi'.Ai h let a; = a:i in Ci :: B^ Mi (7-15) 

a :2 :^2 b let x = X 2 in Ci :: B’^ M 2 

The derivation for (7.15) is of the form: 


Xi'.Ai b xi :: Ai^ xi Xi -.Ai^x-.Ai b ci :: B^ Ni 
xi'.Ai b let a; = a;i in ei :: B^ let a; = a;i in 7Vi 

'-v-" 

Ml 


By inversion: 


XIAi^ xAi b Cl :: B^— y JVi (7.16) 

Variable xi does not appear in ei, so the above is equivalent to: 

x:Ai^ Cl :: B^ Ni (7.17) 


4 


This is the same that we got right before, due to uniqueness of normal forms. 
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Applying Lemma 10 on (7.12) and (7.17) we get: 

• h [vo/x] ei :: [W^i/x] iVi (7.18) 

By E-Let: 

let X = ?;o in ^ [vq/x] ei ( 7 . 19 ) 

Also, by Lemma 2 using (7.13): 

case inji Mqi of inj^ X\ Mi \ inj 2 X 2 => M 2 —>■* 
case inji Wqi of inj^ xi => Mi \ inja X 2 => M 2 

By TE-Case: 

case inji lEoi of inj^ xi ^ Mi \ inj2 X2 ^ M2 —S> [Wqi/xi] Mi 
From the equality: Mi = let x = Xi in A^i, and because xi does not appear in Mi: 

[Woi/xi] (let X = xi in Ni) = let x = Wqi in A^i —[Woi/x] Ni 
From the last relation along with (7.19) and (7.18) stems the wanted result. 

- E[uo] = uo ? ei : 62 : Similar to case Cc ? ei : 62 

- E[uo] = Vo e: Similar to earlier cases. 

- ^[uo] = (Ax.Co) vq: Similar to earlier cases. 

• Case T-A: 

•he:: M TAG(A) n TAG(B) = 0 

•he:: DEkDAiB{M) 


By inversion: 

•he:: M 

TAG(A) n TAG(B) = 0 


( 8 . 1 ) 

( 8 . 2 ) 


There also exists e' such that: 

e — >e' (8.3) 

By i.h. on (8.1) and (8.3) there exists M', such that: 

M —M' (8.4) 

•he':: A-a M' (8.5) 

By Lemma 2 on (8.4): 

DEAD aib{M) —a+ dead aib{M') 

Applying rule T-A on (8.5) and (8.2): 

•he':: DEADau3(A/') 


•4 
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► Theorem 16 (Two-Phase Safety). V e^A^M,T 

(1) ■'re :: M, 

(2) • h M :: T, 

Then, either e is a value, or there exists e' such that: e —> e! and -he':: A^ M' for M', 
such that M — M' and ■ h M' :: T. 

Proof. By induction on pairs A-Rule/Id,-Rule of derivations: 

The:: A^ M 
G'r M -.-.T 

• Cases T-Cst/R-Cst, T-Var/R-Var, T-AI/R-Pair, T-Lam/R-Lam: 

The term e is a value. 

• Case T-Let/R-Let: 

From (1) we have: 


• h Cl :: Ai^ Ml x: Ai \- e2 ■■ A2^ M 2 
■ h let a: = Cl in 62 :: ^ 2 ^ let x = Mi in A'l 2 


By inversion: 

• h Cl :: Ai"-^ Ml 
x:Ai h 62 :: ^ 2 ^ M 2 

From (2) we have: 

•hMi::Ti x'.Ti'r M2 r. T2 
■ h let X = Ml in M 2 :: T 2 

By inversion: 

■'r Ml-.-. Ti 
x-.Ti'r M2 :: T2 

By i.h. using (2.1) and (2.3) we have two cases on the form of ei: 

> Expression ei is a value: 

Cl = Vi 

By source language operational semantics: 
e = let a; = a;! in 62 —> [^^ 1 / 2 :] 62 

> There exists e'l such that: 

ei — e'l 

Hence, by E-ECtx: 


( 2 . 1 ) 

( 2 . 2 ) 


(2.3) 

(2.4) 


(2.5) 


( 2 . 6 ) 


e = let a; = Ci in 62 


let X = e'l in 62 


(2.7) 
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In either case, there exists e' such that: 

e —^ e' ( 2 . 8 ) 

By Theorem 15 on (1) and (2.8), there exists M' such that: 

M — M' 

•he:: ^ 2 ^ M' 

And by Corollary 11: 

• h M' :: T 


• Case T-If/R-If: 

From (1) we have: 

• h Cc :: Bool^ M Vi G {1,2} . • h :: Ali 

• h Cc ? ei : 62 :: Me ? AIi : AI 2 

By inversion: 

(3.1) 

(3.2) 


h Cc :: Bool^ Me 

• h ei :: A^ Mi 

• h 62 :: A^ M 2 


From (2): 


•hMc::Bool Me h Mi :: T ^Me h M 2 :: T 


• h Me ? Ml : M 2 :: T 


By inversion: 


• h M, :: 

Bool 

(3.3) 

Me h Ml 

:: T 

(3.4) 

Me h M 2 

:: T 

(3.5) 


By i.h. using (3.1) and (3.3) we have two case on the form of ec- 
\> Expression Ce is a value: 

Ce = Ve 

By a standard canonical forms lemma Vc is either true or false. Assume the first 
case (the latter case is identical but involving the “else" branch of the conditional): By 
E-Cond-True: 

true ? ei : 62 —ei 


[> There exists e'^ such that: 

6e ^ 6e 


Hence, by E-ECtx: 


Cc ? ei : 62 


? ei : 62 


(3.6) 
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In either case, there exists e' such that: 

e — >e' (3.7) 

By Theorem 15 on (1) and (3.7), there exists M' such that: 

M — M' 

•he:: M' 

And by Corollary 11: 

• h M' :: T 


• Case T-AE/R-Proj: 

Without loss of generality we’re going to assume first projection (the same holds for the 
second projection). 

From (1): 

* h e :: Ax A ^ 2 ^— ^ Afo 
•he:: Ai^ projiMo 

By inversion: 


•he:: A^ A A2 ^ — ^ Afg 


(4.1) 


From (2): 


• h Mq :: Ti X T2 


■ h projiMo :: Ti 


By inversion: 


• h Mo :: Ti x T 2 (4.2) 

By i.h. using (4.1) and (4.2) we have two case on the form of e: 

> Expression e is a value: 

e = V 

So the source term does not step. 

> There exists e' such that: 

e — >e' (4.3) 

By Theorem 15 on (1) and (4.3), there exists M' such that: 

M — M' 

•he:: A’-^ M' 

And by Corollary 11: 

• h M' :: T 


• Case T-App/R-App: 
From (1): 


• h ei :: A —7> Mi 


• h e2 :: A^ M 2 


• h ei e2 :: Mi M 2 
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By inversion: 


■ ei :: A ^ Mi 
• 1~ e2 :: A^— y M ^2 


(5.1) 

(5.2) 


From (2): 


■ h Ml :: r, ^ T ■ h M2 :: T, 
■'r Ml M2 ■■■. [Ma/x] T 


By inversion: 


• h Ml :: ^ T 

• H M2 :: T, 

By i.h. using (5.1) and (5.3) we have three cases on the form of ei: 
\> Expression ei is a primitive value: 

ei = c 

Elaboration (5.1) becomes: 

• h c :: A —> All 

By applying lemma 9 on (5.5) there exists Wi, such that: 

Ml —Wi 
■hcr.A^ B^ Wi 

By Corollary 11 using (5.3) and (5.22): 

• h lEi :: T, ^ T 

By Assumption 3 on (5.7): 

TEi =c 


(5.3) 

(5.4) 


(5.5) 

(5.6) 

(5.7) 

(5.8) 


or 

Wi = DEAD.ia(IFi') 

The latter case combined with (5.8) contradicts Corollary 12, so we end up with: 

IFi = c (5.9) 

By lemma 2 using (5.6): 

Ml M 2 —c M 2 (5.10) 

By i.h. using (5.2) and (5.4) we have two cases on the form of 62 : 

- Expression €2 is a value: 

62 = V2 

Elaboration (5.2) becomes: 

• h U2 :: M 2 (5.11) 


ECOOP’15 




1048 


Trust, but Verify: Two-Phase Typing for Dynamic Languages 


By lemma 9 on (5.11) there exists W 2 , such that: 

M 2 W 2 

• h V2 :: . 4 ^ — ^ IT2 

By lemma 2 using (5.12): 
c M 2 —c W 2 

For the sake of contradiction assume: 

W 2 = DEADbm(W"2) 
for some W^. By (5.4): 

• h IT2 :: T, 

So, by (5.16) and Corollary 12 we have a contradiction. So: 
W 2 ^ DEADbm(W"2) 

By Assumption 1 on (5.7), (5.9) (5.13) and (5.17): 

CV2 —^ [cl(u2) 

“ There exists 62 such that: 

62 —^ 62 

By E-ECtx: 

c 62 —> C 62 


(5.12) 

(5.13) 

(5.14) 

(5.15) 

(5.16) 

(5.17) 

(5.18) 

(5.19) 


> Expression ei is an abstraction: 

61 = Aa:. 6 o (5.20) 

Elaboration (5.1) becomes: 

• h Aa:.eo :: A ^ Mi (5.21) 

By applying lemma 9 on (5.5) there exists Wi, such that: 

Ml —Wi (5.22) 

• h Aa:.eo :: A ^ Wi (5.23) 

By Corollary 11 using (5.3) and (5.22): 

■ h Wi :: ^ T (5.24) 

By Assumption 3 on (5.23): 

Wi = Xx.Mo 


or 

Wi = DEAD.ia^b(W;} 

The latter case combined with (5.24) contradicts Corollary 12, so we end up with: 


Wi = Xx.Mo 

(5.25) 

So (5.1) becomes: 


• h Aa:.eo :: A —)• B^ Xx.Mq 

(5.26) 


By i.h. using (5.2) and (5.4) we have two cases on the form of 62 : 


P. Vekris, B. Cosman and R. Jhala 


1049 


- Expression 62 is a value: 

62 = V2 

Equation (5.2) becomes (for some M 2 ): 

• h U2 :: M 2 

By lemma 9, there exists W 2 such that: 

• h U 2 :: W 2 (5.27) 

For the sake of contradiction assume: 

W 2 = DEADBj^(tE') (5.28) 

for some W^. By (5.4): 

■hW2:: T, (5.29) 

So, by (5.29) and Corollary 12 we have a contradiction. So: 

W 2 ^ DEADb^a(W'} (5.30) 

By Assumption 2 on (5.26), (5.27) and (5.30): 

(Ax.eg) V2 —)■ [v2lx\ eg 

- There exists e '2 such that: 

62 - e '2 (5.31) 

By E-ECtx: 

(Ax. 60 ) 62 —(Ax. 60 ) e '2 

[> There exists 6 ^ such that: 

61 —^ e'l (5.32) 

By E-ECtx: 

61 62 —> e'l 62 


In all cases, there exists e' such that: 

6 — >e' (5.33) 

By Theorem 15 on (1) and (5.33), there exists M' such that: 

M — M' 

•he:: M' 

And by Corollary 11: 

• h M' :: T 

• Case T-VI/R-Inj: Following similar methodology as before. 

• Case T-VE/R-Case: Following similar methodology as before. 

• Case T-T/R-App: 

Corollary 12 contradicts the second premise (2), so the theorem does not apply here. 


•4 
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